Subject: Re: misc. capex comments

From: [email-masked]
Date: Thu, 1 Sep 94 10:54:13 EDT

Frank,

I've imbedded comments to your response below.  I deleted items on
which I had no comments.  General request:  could you put the revised
proposal on the ftp server or on e-mail before it appears in Alan's
next big draft of the spec?
Thanks,
Peter

>>
>> - For CV 88 "Exclusivity", paragraph 2 of the description seems to
>>   state that if you have a MAC addr or NB name list but do not have
>>   CV 88, the receiver should assume you had a CV 88 with the indicator
>>   value of 0x00 ("not exclusive").  I don't like this sort of IMPLIED
>>   stuff, and would very much prefer we have the following rules:
>>      - if you include a MAC addr list CV, the MAC addr exclusivity
>>        list CV must also be included
>>      - if you include a NB name list CV, the NB name exclusivity
>>        list CV must also be included
>>   The converse of these rules is not true, i.e., one could have an
>>   exclusivity CV without the corresponding list CV.  This is currently
>>   discussed in paragraph 3, which now needs a little rework because we
>>   have two exclusivity CVs.  I would like to suggest the following
>>   wording to replace paragraph 3:
>>
>>     For the MAC Address List Exclusivity CV:
>>        A node may specify that it supports no local MAC addresses by
>>        including in its capabilities the MAC Address List Exclusivity
>>        CV (with byte 2 == X'01'), and not including any instances of
>>        the MAC Address List CV.
>>
>>     For the NetBIOS Name List Exclusivity CV:
>>        A node may specify that it supports no local NetBIOS names by
>>        including in its capabilities the NetBIOS Name List Exclusivity
>>        CV (with byte 2 == X'01'), and not including any instances of
>>        the NetBIOS Name List CV.
>
>I believe we discussed this at an AIW and the group was Ok with
>non-exclusive as the default. I think it is too late to change it
>for release 1.

I don't recall the discusssion but I don't care enough to argue the
point.  Your response did not address the second part of my comment,
which was to improve the language of paragraphs #3.  The wording I
suggested is purely an editorial change and is because the current
wording (about what the sender wishes not to receive) implies a filtering
obligation on the capex receiver which does not exist.  If no one
objects to the wording I suggested, I think we should replace the
current, slightly misleading wording.

>
>>
>> - In CV 89 "MAC Address List", the current text reads "MAC addresses
>>   and masks are in canonical in this control vector".  I think this
>>   should be changed to "MAC addresses and masks are in non-canonical
>>   format in this control vector", per our agreement at the AIW.
>
>My notes from the last AIW say that we decided that MAC addresses and
>masks are canonical in the CapEx and non-canonical in the protocol.
>I actually prefer it your way. Can someone help us out here?
>

Notwithstanding your notes and Wayne's recollection, I am sure we agreed
that the MIB would be the different one, and the two functions of capex
and SSP messages would have non-canonical format.  Louise's minutes
(capability exchange section) confirm this:

        4.  New issue:  bit-ordering
In order to match the current RFC 1434, in which MAC addresses are
non-canonical now, it was agreed that the organizationally unique
identifier (OUI) and the MAC address will be non-canonical.  The
DLSw MIB, however, will be canonical to match other MIBs.

>>
>> - In CV 8A "NetBIOS Name List", I think we should explicitly state that
>>   '*' is permitted only at the end of a name.  The text implies it but
>>   should probably state it flat out.  Also, I think we should beef up
>>   the language about names with trailing blanks/nulls to also treat
>>   the case of short names which do not end with '*'.  How about this
>>   for a new 3rd paragraph:
>>
>>      NetBIOS names which have fewer than 16 bytes and which do not
>>      end with '*' are not assumed to have a trailing '*';  the
>>      "wildcard" character must be explicit.  They are also not assumed
>>      to have any particular trailing pad character, and cannot match
>>      names with a different length.  Blanks and nulls at the end of
>>      end of names in this CV are ignored, and should be ignored
>>      in names being compared to these.
>>
>>   (not very well worded, maybe someone else can improve on it ....)
>
>Would it be acceptable to you if I add your first sentence to what is
>already there like so...
>
>    All blanks or nulls at the end of NetBIOS names in this control vector
>    are ignored. NetBIOS names which have fewer than 16 bytes and which do
>    not end with '*' are not assumed to have a trailing '*';  the "wildcard"
>    character must be explicit.
>

The other sentences might be useful, but it's ok if you want to drop them.
To pick up my point about stating flat out the rule on '*' placement,
I would add one more sentence: "'*' is allowed only at the end of a name."

---

From: Frank Bordonaro <[email-masked]>
Date: Thu, 1 Sep 94 8:50:35 PDT

Peter,

My comments below.

> next big draft of the spec?

Yes. I am working on putting the revised proposal into "RFC format" so
Allen can easily make the changes to the spec. I was hoping to have it out
by the end of the week, but will wait until the "canonical" issue is
resolved (see below).

> current, slightly misleading wording.

I could have sworn I reworded this in the last posting. To save cycles 
discussing this further, we will use your wording above.
 
> DLSw MIB, however, will be canonical to match other MIBs.

I agree that this is the right way to go, but I was concerned that we needed
to hear a few more voices before changing it. Since Louise's minutes confirm
your position, let's leave it open for discussion for 2 weeks and if we don't
hear any objections, we'll go with non-canonical. This should be enough time 
for vacationers to speak up.

> I would add one more sentence: "'*' is allowed only at the end of a name."

Good point. It has been added.

Regards,
Frank